X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C9356D.E51B865A@onstor-exch02.onstor.net>; Thu, 23 Oct 2008 17:17:26 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C9356D.E51B865A"
Content-class: urn:content-classes:message
Subject: RE: Lun Label type-5 Functional Spec. for Kegg
Date: Thu, 23 Oct 2008 17:17:26 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E038F9140@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0C19C9C2@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Lun Label type-5 Functional Spec. for Kegg
Thread-Index: Ack0pDOGwsjJ1gNkTEyXhNf4IHF7KQAiul2wAAEHxdAAAFt/oAAAU/bAAAMjlBAACggvEA==
From: "James Kahn" <james.kahn@onstor.com>
To: "Deepak Veliath" <deepak.veliath@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>,
	"dl-Kegg" <dl-Kegg@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9356D.E51B865A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



_____________________________________________
From: Deepak Veliath=20
Sent: Thursday, October 23, 2008 1:52 PM
To: dl-Design Review; dl-Kegg
Subject: RE: Lun Label type-5 Functional Spec. for Kegg

Hello Jim,
*	From reading the spec I understand you are making space appended
to a physical LUN accessible by exporting them as partitions or as you
call them, LUN extents.  What would the device IDs for these partitions
be as displayed by "lun show disk"?

	There are various defined extent (aka volume) types define.
Thus far, all we really do is give the allocated extent
	to a volume.  There are several details to be ironed out before
multiple extents become extensively used.
	That will be an issue for a future functional spec.   Perhaps we
should talk about future direction on this subject...

*	From the Figure 10 it would seem there is only a single owner
block for the whole physical LUN.  Does this mean that only a single
node in a cluster can access the partitions at any given time.

	The idea is to provide a well-known location for the owner block
so outcluster access can be controlled as well as
	Limiting access by other nodes in the cluster.

*	If a partition has no FS on it, does it make to append space
added to the physical LUN to be added directly to the partition?

	At this time the last free extent of the LUN would own any
expanded capacity added to a LUN.  This is the up-side
	of variable-size LUN extents.  (The down-side is fragmentation.
That becomes an issue once multiple extents=20
	are being used.)

	 If a volume was already created using the LUN, it would not
suddenly get the new capacity.  On down the road, auto-grow would be
updated to allow the volume to grow into the expanded LUN capacity. This
is fairly straight forward for a single LUN volume.  A bit more
complicated for a multi-lun volume.   And I would think that customers
would want a policy knob to control this behavior.

*	Regd Solaris disk-labels, AFAIK on an Intel based system Solaris
creates a PC MBR, allocates the whole disk (skipping the 1st track) to a
primary partition of type 0x82 and slices that partition up using its
native partitioning logic which I believe is very similar to the BSDs.
So I believe we're safe on x86 systems running Solaris (which in turn
means Leopards can co-exist with Cougars on the SAN?).

Yes, if Sun honors PC MBR labels, then the new type-5 LUNs we can
co-exist.

This new label has lots of headroom for future growth,
JIm

------_=_NextPart_001_01C9356D.E51B865A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Lun Label type-5 Functional Spec. for Kegg</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Deepak Veliath<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Thursday, October 23, =
2008 1:52 PM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> dl-Design Review; =
dl-Kegg<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> RE: Lun Label type-5 Functional Spec. for =
Kegg</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">Hello Jim,</FONT></SPAN></P>

<UL>
<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">From reading the spec I understand you are making space =
appended to a physical LUN accessible by exporting them as partitions or =
as you call them, LUN extents.&nbsp; What would the device IDs for these =
partitions be as displayed by &quot;lun show =
disk&quot;?</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></LI></DIV>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">There are various defined extent (aka volume) types =
define.&nbsp; Thus far, all we really do is give the allocated =
extent<BR>
to a volume.&nbsp; There are several details to be ironed out before =
multiple extents become extensively used.<BR>
That will be an issue for a future functional spec.&nbsp;&nbsp; Perhaps =
we should talk about future direction on this subject</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">&#8230;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">From the Figure 10 it would seem there is only a single =
owner block for the whole physical LUN.&nbsp; Does this mean that only a =
single node in a cluster can access the partitions at any given =
time.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></LI></DIV>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">The idea is to provide a well-known location for the =
owner block so outcluster access can be controlled</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">as well as</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Limiting access by other nodes in the =
cluster.</FONT></SPAN></P>

<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">If a partition has no FS on it, does it make to append =
space added to the physical LUN to be added directly to the =
partition?</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></LI></DIV>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">At this time the last free extent of the LUN would own =
any</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial"> expanded</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial"> capacity added to a LUN</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">.&nbsp; This is the up-side<BR>
of variable-size LUN extents.&nbsp; (The down-side is =
fragmentation.&nbsp; That becomes an issue once</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">multiple</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">extents<BR>
are being used.)</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">&nbsp;If a volume was already created</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">using =
the LUN, it would not suddenly get the new capacity.&nbsp; On down the =
road, auto-grow would be updated to</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">allow =
the volume to grow into the expanded LUN capacity</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">This is =
fairly straight forward for a single LUN volume.&nbsp; A bit more =
complicated for a multi-lun volume.&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us">&nbsp;<FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">And I =
would think that customers would want a policy knob to control this =
behavior.</FONT></SPAN></P>

<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">Regd Solaris disk-labels, AFAIK on an Intel based =
system Solaris creates a PC MBR, allocates the whole disk (skipping the =
1st track) to a primary partition of type 0x82 and slices that partition =
up using its native partitioning logic which I believe is very similar =
to the BSDs.&nbsp; So I believe we're safe on x86 systems running =
Solaris (which in turn means Leopards can co-exist with Cougars on the =
SAN?).</FONT></SPAN></LI></DIV>
<BR>
</UL>
<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Yes, if Sun</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">honor</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">s</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial"> PC MBR =
labels, then the new type-5 LUNs w</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">e can co-exist.</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">This new label has lots of headroom for future =
growth,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">JIm</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C9356D.E51B865A--
